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SYSTEM AND METHOD FOR PROVIDING A PLURALITY OF 
PROGRAMMING SERVICES IN A TELEVISION SYSTEM 

Technical Field 

This invention relates in general to television systems, and more 
particularly to a system and architecture for providing a plurality of 
different classes of video and multimedia programming and including the 
logical interface method for accessing said plurality of video and 
multimedia services. 

Background of the Invention 

The old definition of television services included a channel which 
was essentially nothing more than an analog broadcast video source. 
However, in the brave new world of digital programming, the home 
communication terminal ("HCT") otherwise known as the settop box has 
become a more powerful computing_device than the typical analog cable 
TV set-top. In addition to supporting traditional analog broadcast video 
and functionality, these devices must also support an increasing number 
of services which are not analog (but rather digital), are not broadcast 
(two-way communication as for example E-mail), and are not video (such 
as web browser). These are all in addition to a host of other television 
services which are increasingly being demanded by customers, examples 
of which include audio and audio visual programming, advanced 
navigation controls, interactive program guides, impulse pay-per-view 
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captivation, video on demand programming, advanced configuration 
controls, and other online services to name but a few. In order to provide 
these more powerful and complex features, the simple channel 
abstractions need to be extended beyond those which have traditionally 
5 been provided. 

With the capabilities of advanced one-way digital networks, a 
multiplicity of applications become feasible such as downstream e-mail 
delivery, electronic magazines, electronic newspapers, and other 
graphical and textual services for news, sports arid financial information, 

10 to name but a few of broadcast authorizable services. With the 

capabilities of a two-way, digital network other applications such as 
impulse pay-per-view, video on demand, electronic commerce and web 
browsing become possible. All these services can be offered in parallel 
with conventional broadcast television and can be considered differing 

15 service categories. As the number of services available via cable or 
satellite television increases, there is a need for a model in which the 
television viewer can access these services. Given that a viewer of newer 
generation digital HCTs can access up to thousands of channels and 
services available, there will be a large amount of service and channel 

20 definition information that needs to be transmitted from the headend or 
server location to the client or HCT. Traditional methods of broadcast 
television and services in cable television systems do not provide the 
necessary amounts of information to support all these channels and 
services, nor are they capable of efficiently transmitting, storing, 
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accessing, and processing the corresponding large amounts of information 
in the HCT. 

Cost limitations on HCT manufacture impose limitations in 
compute, memory, and internal machine bus bandwidth that in turn limit 
5 the amount of compute resources required to implement increasing digital 
video and multimedia functionality. Consequently, it would be desirable 
to provide a system in which required service related information is 
transmitted from the headend to the HCT in a methodical fashion so as to 
minimize: required network transmission bandwith; time to organize the 

10 information for storage in the HCT; memory footprint of the information 
in the HCT; and the amount of time required to then access the 
information in the HCT. Additionally, this information must be updated 
in an efficient manner such as that when the services and channel lineup 
are changed the HCT is provided the new information. 

15 It would also be desirable to provide this system and method in 

which a particular application for a specific service is preloaded on the 
HCT and, if not, arrange for it to be acquired from the headend and 
loaded. This, of course, would require the ability to have two-way digital 
cable TV network for communication between the headend and the HCT, 

20 or an advanced one-way digital network in which system and method 

acquires specific broadcast service information by accessing and retrieving 
data with a predetermined file name and identification, such file retrieved 
from a broadcast file system ("BFS"). 
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Accordingly, there exists a need to provide a mechanism whereby 
applications on the HCT can be activated from the server via a signaling 
message received from the HCT, to provide the user with services such as 
Emergency Alert Messages, email, and other messaging. 

5 

Brief Description of the Drawings 

FIG. 1 is a block diagram of a cable television system in accordance 
with the present invention; 

FIG. 2 is an electrical block diagram of a settop terminal included 
10 in the cable television system FIG. 1, in accordance with the present 
invention; 

FIG. 3 is a block diagram service application manager service table 
for a cable television system, in accordance with the instant invention; 
FIG. 4 is a block diagram representation of the display channel 
15 table used in connection with the service application manager of the 
instant invention; 

FIG. 5 is a block diagram representation of a split channel table 
used in connection with the service application manager, in accordance 
with the instant invention; 
20 FIG. 6 is a block diagram representation of a bulk table used in 

connection with the service application manager in accordance with the 
instant invention; and 
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FIG. 7 is a block diagram representative of a logo table used in 
connection with the service application manager, in accordance with the 
instant invention. 

5 Detailed Description of the Preferred Embodiments 

While the specification concludes with claims defining the features 
of the invention that are regarded as novel, it is believed that the 
invention would be better understood from a consideration of the following 
description in conjunction with the drawing figures in which like reference 

10 numerals are carried forward. 

Referring now to FIG. 1 there is illustrated therein a block diagram 
of a cable television system 100 including a headend 105 for receiving 
satellite television signals, demodulating the signals down to base band, 
and transmitting the signals over the system 100. The transmitted 

15 signals can, for instance, be radio frequency (RF) signals, although they 
may more preferably be optical signals that are transmitted over a 
communications medium such as a fiber optic cable 125. When optical 
signals are transmitted by the headend 105, one or more nodes 110 are 
included in the system 100 for converting the optical signals to RF signals 

20 that are thereafter routed over other media such as coaxial cables 130. 
Taps 115 are provided within the cable system 100 for splitting the RF 
signal off to subscriber equipment, such as settop terminals 120, cable 
ready televisions, video cassette recorders (VCRs) or computers. 



5 
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Referring now to FIG. 2, there is illustrated therein a block diagram 
of the home communication terminal 120 and other system equipment is 
shown. The terminal 120 is typically situated within the residence or 
business of a subscriber. It may be integrated into a device that has a 
5 display 235, such as a television set, or it may be a stand alone unit that 
couples to an external display, such as a display included in the computer 
or a television, and that processes television signals for presentation to 
subscriber on the display. The terminal 120 preferably comprises a data 
port 205 for receiving the RF signals, which can include video, audio and 

10 data information, from the tap and providing any reverse information to 
thej;ap for transmission back to the headend. The terminal 120 further 
includes a processor 210 for controlling operations of the terminal 120 and 
for driving the display, a clock 215 for providing timing functions, and a 
tuner 134 for tuning into a particular audio, video, and/or data channel. 

15 Additionally, the terminal 120 includes a receiver 220 for receiving 
externally generated information, such as viewer inputs or commands 
from other devices. Viewer inputs could, for example, be provided via 
transmitter 240, such as buttons or keys located on the exterior of the 
terminal 120 or a handheld remote control device that includes user 

20 actuated buttons. Additionally, in certain embodiments, terminals 

include interface connectors for Ethernet port, Serial port, and Universal 
Serial Bus port. 

A memory 250, such as a nonvolatile volatile random access, 
memory, coupled to the processor stores operational parameters such as 
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commands that are recognized by the processor. The memory also stores 
program and application information that can, for instance, be 
downloaded over the system to the terminal. The program information 
includes program guide information that is displayed for the subscriber in 
the format of a program guide including a listing of channels, programs for 
viewing on the channels, and times during which the programs are shown. 
The program information also includes channel information such as the 
channel number and identification information, e.g., ESPN, Disney, 
WXIA, etc. 

As noted above, in the world of digital programming, services are no 
longer considered to be simply traditional analog broadcast services, but 
will include advanced one-way digital network services and a whole host 
of additional two-way services such as web browsing, video on demand, 
and E-mail to name but a few. In order to provide these more powerful 
and complex features, the simple channel abstraction needs to be extended 
so as to provide for each of these different services in both one-way and 
two-way digital networks. The instant invention provides a Service 
Application Manager ("SAM") system and method that implements a 
model in which a viewer can access services. Each service identification 
consists, for example, of an application to run and a parameter, such as 
data content, specific to that service. Many services may be defined using 
the same application component, however with different parameters. For 
example, an application that can tune video programming would be 
executed with one set of parameters to view, for example, HBO, and a 
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separate set of parameters to view, for example, CNN. Each association of 
the application components (in this case tune video) and one of the 
parameter components (i.e., HBO or CNN) represents a particular service 
that has a unique service identification. Each of the other services 
5 described above, such as text channels, pay-per-view, video on demand 
and web browsing fit nicely within the service model. In addition to an 
application and parameter, each service also has an identity, which may 
include a short textual description (such as call letters for a particular 
television station), a long textual description, and a logo image. 

10 Additional service attributes in certain embodiments include 

multimedia service attributes. A service's identity is optionally 
augmented with an introductory audio that is played when the service is 
launched. A short "Welcome to ABC" song or voice with musical 
background, where such audio is distinctively associated with service is an 

15 example. Likewise, a service's identity is optionally augmented with an 
audio for when service is terminated or suspended. 

In other embodiments, a special effect when starting a service, 
including animated transition into the service such as morphing from an 
image of service logo to displayable service, or graphics transitions such as 

20 implosion and fades, may be associated with the service. Likewise, a 
special effect may be associated with a service when it is terminated or 
suspended. 

In another embodiment, any of a partial or full-size image, video or 
video widget serving the function of a 3-D logo is associated with a service 
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and displayed momentarily when service is launched. Same or different 
counterpart media is employed for service termination or suspension. The 
specified association of media with service may include an amount of time 
to display or play the media. Additionally, media can be combined with 
5 special effects. 

Service attributes may or may not necessarily be for identification 
services but for efficiency of system and method. Such service attributes 
include: cable-operator-only launchable service messaging viewer with 
emergency alerts or reminders to pay bill. A service can be classified with 

10 an attribute as both, a cable-operator and viewer, launchable service. 
Alternately, a service attribute is an installer-only or repair- 
representative-only launchable service. 

A service can be classified with an attribute as one that can be 
launched by time, rather than immediately to responding to viewer input 

15 or headend signaling. Furthermore, such service activation time is 
designated by: 

A. a prespecified time after viewer activation or server signaling; or 

B. input by viewer or data transmitted during server signaling, 
and/or possibly with: 

20 1. periodic pre-specified interval values; or 

2. periodic pre-specified interval values specified by 
viewer or headend message. 
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Examples of a service that is launched periodically is a ticker-tape that 
displays periodic information updates of sports scores or stock prices. 
Specification of service display duration is included appropriately in the 
aforementioned. A service can also be classified with an attribute as a 
5 "service not-blockable by viewer" that is activated by cable headend 
operator. 

A service may have the attribute of a background-service, not 
visible to viewer. In a HCT, a service that enables HCT to route Internet 
Protocol data or other information received from and to digital network 
10 and passed via one of many possible HCT communication ports to and 
from one or more of many computing devices in the viewer's premises, 
establishes a communication link between the digital network and 
computing devices. Such computing devices include an advanced phone, a 
hand-held electronic organizer device, a personal computer, an appliance 
15 such as a stove, and therefore the HCT acts as a cable modem. 

Although a service runs in the HCT in the forementioned, the 
application running on the HCT serves as an "enabler" and possibly as a 
communication switch while the designated computing device and 
communication port are specified as parameters of the service. HCT 
20 communication ports include Ethernet port, serial port, Universal Serial 
Bus (USB), to name a few. 

In order to access this growing number of services, it is necessary to 
provide a system which can meet functionality, efficiency, and memory 
footprint requirements constrained by the capabilities of the HCT. The 

10 
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Service Application Manager ("SAM") architecture consists of a SAM 
server component, a SAM client component, and the interface between-the 
server to the client. This interface consists of the SAM information tables 
broadcast on the BFS (an example of which is disclosed in commonly 
5 assigned patent application serial no. PCT/US97/22535, the disclosure of 
which is incorporated herein by reference) and the update and signaling 
messages passed from server to client. In the context of the system 
illustrated in Figs. 1 and 2, the SAM server component is part of the 
headend, while the SAM client component resides in the HCT. The SAM 

10 server stores the current SAM information which consists of a Service 
Table, a Display Channel Table, a Split Channel Table, the Bulk Table, 
and the Logo Table. The SAM provides an interface for a server operator 
to enter and modify the information on the SAM, and to broadcast it to 
SAM clients notifying them of, for example, information changes. The 

15 SAM also allows the applications which execute a particular service to be 
introduced into the system. Each application has a server component and 
a client component. The application server may execute all the time, 
while an application client may be downloaded to the HCT and executed 
only when the viewer requests the service be activated. 

20 The SAM server provides an interface through which applications 

are placed on the network, services registered, a channel lineup specified, 
and the SAM information stored and modified. The SAM server may also 
allow changes to the SAM information table (as described herein below) to 
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be posted to the network together with a time specified by the cable 
operator. 

The SAM client provides an interface through which applications 
may be activated and SAM information can be accessed. One functionality 
5 of the SAM client is the activation of an application client on the HCT, 
either to provide a specified service or because of a signaling message from 
the server. 

As noted above SAM information includes at least five different 
tables: a Service Table stores information about all services available on 

10 the system and each service is identified by a specific service ID; a Display 
Channel Table ("DCF) provides an abstraction to match a display channel 
number to a service ID (and vice versa); a Split Channel Table 
supplements the DCT with information about split channels; a Bulk Table 
is provided for storing actual string and parameter data as well as 

15 attributes of each service. The data for each table may be transmitted 
from the server to the client by writing it into a binary file and then 
placing the file on a broadcast file system ("BFS") such as that disclosed in 
the aforementioned copending PCT Patent Application, the disclosure of 
which is incorporated herein by reference. Updates to the various table 

20 increments the tables' version number. Accordingly, the system will 
always access the most recent version of a particular table. This is 
important as some channels, for example the Split Channel Table, will 
change fairly regularly and indeed can change on a daily basis. 
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When the SAM server changes the SAM files being broadcast on 
BFS, the SAM client will receive a message from the SAM server via the 
HCT operating system. This message contains the current version 
number of each SAM table, as well as flags optionally specifying a "forced" 
5 update of each table. For each table, the SAM client will check the version 
number specified in the message versus the local table versions and only if 
they are different retrieve the file from the BFS and check the version 
number a second time (unless the "force" flag is set for that table, in which 
case the file on BFS is always checked). If a file version being transmitted 

10 on the BFS is different than the local file stored in the SAM client, the 
SAM client will update its tables using the new files. 

The update process works such that while the SAM client is reading 
new files, the old files are still available to applications on the HCT. Only 
when the SAM client has completed reading any new tables does it 

15 actually update the current tables to the new information. During this 
very brief "swap", both old and new tables are locked such that the data 
cannot be accessed via the SAM client interface. 

The update process is also robust such that the SAM client can 
handle the various non-deterministic aspects of the SAM server's use of 

20 the BFS. For example, the synchronization of the message being received 
at the client, the file being changed on the BFS server, and the file being 
changed as seen by the BFS client are all affected by network latency and 
could happen in different orders. 

13 
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After receiving an information update, the SAM client will notify 
interested applications via the HCT OS that the SAM information has 
changed. To allow other components to update their service and channel 
related information, the SAM client must keep the last version of the 
5 replaced data tables in memory. 

The various SAM information tables are transmitted in band, over 
QAM, for fast access by the SAM client during HCT boot. Copies of the 
tables, with the exception of the Logo Table, are also transmitted out-of- 
band, over QPSK. The out of band files are used by the SAM client during 
10 SAM information update such that the viewer's use of the HCT is not 
interrupted (access to in-band data requires use of the HCT tuner). 

Referring now to FIG. 3 there is a block diagram representation of 
the Service Table used in the preferred embodiment of the Service 
Application Manager, all in accordance with the instant invention. The 
15 Service Table 300 contains the service identification information, with 
each service assigned a unique service ID. The header information at the 
beginning of the Service Table includes the table version 308 and the 
number of sub tables 310. This is followed by the service subtables. Each 
subtable 302 includes the number of subtable entries, the length of the 
20 service data segment, an index, and finally the service data segment. The 
index includes a pairing of a service ID and the offset into the data 
segment where the service data is actually found. Accordingly, if a 
particular subtable provides information relating to 25 different services, 
the index will include 25 blocks, each block corresponding to a single 

14 
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service. The service IDs 306 across the entire Service Table are stored in 
increasing order, but are not necessarily contiguous. Each service 
subtable can store up to 64Kb of service data. 

To find a service ID in the Service Table, a binary search is done 
5 first on the subtables to determine which subtable a service ID is in, and 
then within the index of the subtable to locate the offset of the service data 
in that subtable. The offset is then used to access the data directly. 

Each service data record includes all of the service attributes. One 
such attribute is a description ID. The description ID is an index into the 

10 Bulk Table for the string describing the service. In one embodiment, each 
string is made up of three fields: (1) an ascii string decimal number 
specifying the length of the short description in characters; (2) a short 
description ascii string; and (3) a long description ascii string. For 
example, the following strings describe a service whose short description is 

15 "WTHR", and the long description is "The Weather Channel": "4WTHR 
The Weather Channel/' 

A second piece of data which is located in the data block 320 is a 
logo ID and which itself is an index into the Logo Table for the service's 
logo pixel map. An application Universal Resource Locator ("URL") ID is 

20v a third index into the Bulk Table for the URL string identifying the 

application client in the broadcast file system. The final attribute is an 
application dependent parameter, which is interpreted as a number (i.e., 
a source ID) or an index into the Bulk Table for a parameter string or 
parameter data. 

15 
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In order to efficiently store service records for thousands of services, 
the invention specifies a record with variable-length fields. The idea is to 
use only as much memory for a field as is needed for the particular value 
of that field. The field Size attribute of the service is used to specify the 
5 size, in bytes, of each field. The field Size byte uses 2 bits to encoding the 
number of bytes minus 1 for each field. A value of "00" in a field means it 
is 1 byte, "01" means 2 bytes, etc. No matter what the actual field size, 
the access operations always return the field value in 32 bits. The access 
routines must operate at a byte level when retrieving fields larger than a 
10 byte because the data will not be word or half-word aligned. The format of 
the field Size byte is shown below: 

field Size: for(i = bit 0; i < 8; i++) { 

description ID size -1:2 
logold size -1:2 
15 applicationld size -1:2 

parameter size -1:2 

} 

Thus, each record varies in length from 5 to 17 bytes. 

Accordingly, and referring now to FIG. 4, there is illustrated therein 
20 in a block diagram representation of the Bulk Table used in connection 
with the Service Application Manager, all in accordance with the instant 
invention. The Bulk Table 400 contains data relevant to the services, 
such as strings for descriptions, application URLs, and parameter data. 
As with the Service Table 300 of FIG. 3, the Bulk Table comprises several 

16 
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initial entries 402, 404 as described above, followed by a plurality of bulk 
information subtables 406 and 408. 

Each subtable includes the number of subtable entries, the length of 
the bulk data segment, an index, and finally the bulk data segment. The 
5 index includes a pairing of a bulk ID and the offset into the data segment 
where the bulk data is actually found. Accordingly, if a particular 
subtable provides information relating to 25 different bulk data entries, 
the index will include 25 blocks, each block corresponding to a single bulk 
data item. The bulk IDs across the entire Service Table are stored in 

10 increasing order, but are not necessarily contiguous. Each bulk subtable 
can store up to 64Kb of bulk data. 

To find a bulk ID in the Bulk Table, a binary search is done first on 
the subtables to determine which subtable a bulk ID is in, and then within 
the index of the subtable to locate the offset of the bulk data in that 

15 subtable. The offset is then used to access the data directly. 

The size and the contents of the Bulk Table itself depends on the 
size and type of information which is required to be stored therein. 
Several types of BulkData are defined in the following. The application 
URL is simply a NULL-terminated ASCII string. The service description 

20 is two concatenated NULL-terminated ASCII strings, the first being the 
short description and the second being the long description. For example, 
"WGNX\0CBS Atlanta\0" is a possible description string. A string is 
simply a NULL-terminated ASCII string. Arbitrary data can be stored in 
the Bulk Table and a pointer to that data handed out via an API in the 

17 
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SAM Client. It is then up to the application client to interpret the content 
of the data. 

Referring now to FIG. 5, there is illustrated therein a block diagram 
representation of the Display Channel Table used in connection with the 
5 Service Application Manager, all in accordance with the instant invention. 
The Display Channel Table 500 is used to map service IDs to channel 
numbers displayed to the viewer (Display Channel Number, or DCN). In 
one embodiment of a cable system using the SAM, the Display Channel 
Table can be specified on a per-hub basis. This allows different 
10 neighborhoods of subscribers to receive different channel lineups. 

The Display Channel Table is constructed to allow optimal access 
time to determine the service ID for a particular service or the service ID 
for a particular DCN. Both transformations are required by applications 
executing in the HCT such as the channel navigator and the program 
15 guide. 

The Display Channel Table begins with a version number 502, the 
number of valid channels in the channel index 504, and the length of the 
valid service index 506. This is followed first by a valid channel bitmap 
508, containing a bit for each channel in the cable system. For each 
20 channel that is valid, the corresponding bit position is set in the valid 

channel bitmap. Next is a valid channel index 510, each entry associated 
with a valid channel in the bitmap, whose content is an index into the 
service/DCN index that follows. The service/DCN index contains an entry 



18 



BNSDOCID: <WO 9957905A1 J_> 



WO 99/57905 PCI7US99/09278 
for each valid service ID and Display Channel Number pair. Within each 
Display Channel Number in that pair 

is a channel flag (the most-significant-bit of the DCN). This flag indicates 
whether or not the DCN is surfable, i.e. can be reached by the user 
5 incrementing or decrementing throughout the channel lineup. There 
exists a service ID/DCN pair for every combination of service and DCN, 
where a service can be associated with more than one channel. 

These data structures can be better understood by explaining how 
the translation for service ID to DCN and vice-versa takes place. To 

10 translate from DCN to service ID, first the bit for the DCN in the valid 
channel bitmap is checked. If the bit is set, the channel is valid, and the 
index for that channel must be determined. The index is exactly Nth valid 
channel which the DCN happens to be, or the number of bits set in the 
valid channel bitmap up to and including the bit representing the DCN. 

15 This lookup is made compute efficient by using a table which stores the 
number of bits set in a single byte for each decimal value of that byte. 
Thus, the channel index can be determined by taking the decimal value of 
each byte in the valid channel bitmap, translating the decimal value to a 
"number of bits set" using the lookup table, and accumulating this count 

20 for each byte in the valid channel bitmap up to the byte for the DCN. The 
remaining bits in the byte where the DCN bit is located are added by 
shifting and masking. 

The number of bits set is then directly the Nth valid channel for 
that DCN, which is directly the offset into the channel index for that DCN. 
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The channel index contains the offset into the service/DCN index for that 
DCN. Once this offset is known, the service ID for that DCN is the upper 
two bytes of the 32-bit service ID/DCN value. The total search time is 
then O(n) where n is the number of total possible channels. This is 
5 achieved without having to store for example an array of size total number 
of channels, using only an array of size total number of channels divided 
by eight (the bitmap) plus an array of size number of valid channels. 

To look up a service ID for a DCN, a binary search on the service 
ID/DCN index 512 is done. This index is sorted in increasing order, such 

10 that the search is 0(log (number of valid service/DCN entries)). 

In addition to the services described above, the SAM supports the 
ability to split channels provided over the system. A split channel is one 
in which there is more than one service which is provided on that channel 
during a 24 hour period. One embodiment of the SAM may support split 

15 channelsj where each of which shows two services, and which may change 
between those two services up to three times in a 24 hour period. For 
example if the channel is specified as a split channel with service X and 
service Y, starting at midnight the following splits are available: XY, 
XYX, XYXY. Split channels are identified in the Display Channel Table in 

20 both the channel index and the service ID/DCN index using a reserved 
constant. This indicates to the SAM client to lookup the information for 
the requested DCN in the Split Channel Table. There is always a Split 
Channel Table for each Display Channel Table in which a split channel is 
identified. 
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Accordingly, referring now to FIG. 6, there is illustrated therein a 
block diagram representation a Split Channel Table 600 for use in . 
connection with the Service Application Manager, all in accordance with 
the instant invention. The Split Channel Table, like the other tables, 
5 includes a number of initial entries such as initial entry 602 and 604. 
Initial entry 602. is version which specifies the most recent version of the 
split channel table allowing the SAM system to know that it is working 
with the most recent version of information. The second entry 604 
specifies the number of split channels in the channel lineup. Accordingly, 

10 and in FIG. 6, the number of split channels identified would be one as only 
one split channel record 606 is illustrated in split channel table 600. It is 
to be understood, however, that any number of split channels may be 
supported by this system, and the invention is not so limited. The split 
channel record 606 includes a number of pieces of information, including, 

15 for example, the DCN being split 608, the identities of the services which 
are splitting the channel 610 and 612, and a time flag 614 which specifies 
the hours at which services are being provided on the channel. These 
times are specified such that service 1 is on by default at midnight in any 
given day. Each time then marks a swap to service 2 and back, continuing 

20 according to the number of swaps. The core channel management 

application in the HCT uses this information such that service swaps take 
place automatically and are done by the client. This differs from existing 
analog systems where split channels are implemented by changing the 
content which is broadcast on a particular analog channel. The split 
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channel concept in ttfis invention also allows channels to be split between 
video services and services of other media, such as text channels or web 
browsing time. 

The final SAM information table present in the instant invention is 
5 the Logo Table as illustrated in FIG. 7. The Logo Table 700 stores service 
logo data. The SAM server provides two different Logo Tables on the BFS, 
both transmitted in band. One table provides the default set of logos 
known by the SAM Server upon deployment of the cable system, in the 
present embodiment the range of default logo IDs is from 1-255 and is 
10 published including the name of the logo. The data for the default logo 

images can be stored in the nonvolatile memory of the HCT such that they 
can be retrieved very quickly and rendered by applications in the HCT. 
The set of default logos will never change, nor will the data in the default 
Logo Table. 

15 New logos registered with services by the SAM server are stored in 

another Logo Table. The SAM client always loads this table into memory 
on the HCT during initialization, and it can be updated like any of the 
other SAM information tables. Accordingly, the Logo Table initial entry 
702 relates to version numbers of the table. 

20 All logos are encoded by the SAM Server using an encoder that 

translates a single common image format such as GIF into the particular 
format that the SAM is transmitting (and decoding within the SAM 
Client). 
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Application clients can access the logo data in the SAM in several 
ways. First, an application client can ask for the logo ID that corresponds 
to a particular service. If the logo ID is stored by the application client 
, (one of the default logos), it can then draw the appropriate logo using its 
5 own data. Otherwise, the application client can ask the SAM client for the 
logo pixmap data, width, and height in a format compatible with the HCT 
OS drawing capabilities, A Logold of zero means no logo. 

The structure of the Logo Table begins with a version number 702, 
number of logos 704 in the table, first logo ID in the table 706, and then 

10 the size of the logo data 708. Next is an index of logo data offsets 710, 

such that index equals the logo ID minus the starting logo ID of the table. 
The index for a logo contains the offset into the logo data segment where 
the actual image data for the logo is stored. 

The primary functionality of the SAM is the activation of an 

15 application client on the DHCT, either to provide a specified service or 
because of a signaling message from the server. Typically the user of the 
DHCT will access services via the Display Channel Number (DCN). The 
SAM uses the Display Channel Table (DCT) to map a DCN to a Serviceld. 
"Split" channels are supported^ such that one channel might provide 

20 multiple services, depending on the time of day. Given a service ID, the 
SAM Client first extracts the appropriate application URL BulkDatald 
from the Service record in the current Service Table, and then the actual 
URL string from the Bulk Table. It then asks the HCT Operating System 
("OS") if the module with the application URL for the application is loaded 
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in the HCT memory. If not, it requests that the OS load the module using 
the application URL. Once the application code is resident in the HCT, 
the SAM client launches the application module as an OS application (it 
may be that the application has already been launched). It then asks the 
5 OS to activate the application, given the module handle-this brings the 
application into focus. Finally, the SAM client sends a kEt_Activate 
message to the application client, including the service ID and the service 
parameter from the Service Table. 

Application clients can also be activated by a message sent from the 

10 server. The SAM client must register with the HCT operating system to 
receive SAM signaling messages. The content of these messages is an 
application URL to activate and the data to pass the application as a 
parameter. The SAM client thus provides a mechanism whereby an 
application client can be activated given the application URL and some 

15 data. If the data type is an integer value, meaning the parameter itself, 
then it is passed directly to the application identified by the URL via a 
kEt_Activate message. However, if the parameter is a string or data, then 
it must be stored by the SAM client locally and given a BulkDatald in the 
range reserved for private client use. The SAM client will activate the 

20 application client. The BulkDatald is passed as the parameter, and a 
special id is used to signify a service activated via a pass-thru message. 
The application client can then use the SAM client API to retrieve the 
data given the bulk ID. Depending on the application, the private bulk 
data might be a URL string, an actual string to use directly, or data. The 
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application client must be given the parameter type it is expecting; this 
must be verified by the SAM Server before the signaling message is sent. 
However, if the application client is expecting a string it must check 
whether the string is a URL or the content itself. If the application client 
is executing on behalf of the kSamJSignalingService, then it must delete 
the private bulk data when it suspends 

The SAM client can be asked to construct a kEt_Notify event with 
supplied parameters and forward it to designated application clients. 
Again, this can be done via a service ID or an application URL. The 
notification event type is supplemented with event data particular to the 
notification being sent (such as kEdJSamDataUpdated), an ID (typically 
the service ID), and two parameters. 

The SAM client provides a facility whereby application clients can 
be queried to determine whether particular services are currently 
authorized. The SAM will look up the application URL for the requested 
service ID in the Service Table, and send the application client a 
kEt JsAuthorized event requesting an asynchronous reply to a queue 
created within the SAM client API. The SAM client will wait on that 
queue until a kEt_AsyncResponse event is delivered by the application 
client, and then return the result to the caller of the SAM API. Thus, 
while the internals of the authorization query are asynchronous, the SAM 
Client API is synchronous. It is up to the application client to determine if 
the service is authorized, using whatever means necessary. 
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Application clients can be suspended by Serviceld or directly via 
application URL. Application clients can also be suspended as a result of 
a signaling message from the SAM Server. 

Accordingly, in the system illustrated in Figs. 1 and 2 it may be 
5 appreciated that the channel selection function of this system includes a 
plurality of channel cross reference tables as illustrated in Figs. 3-7. 
These tables cross reference settop terminal channels with a variety of 
television services, or other services, such as various types of video and 
audio programming, and online services such as web casting and E-mail. 

10 Selection of a particular channel transfers control of that specific 

application program, along with one or more appropriate parameters 
obtained from the cross reference tables, and activates the service 
associated with that selected channel. In sum, the cross reference tables 
in Figs. 3-7 are channel selection functions which enable the settop 

15 terminals to execute software and activate a variety of services. When a 
viewer of the system of FIG. 1 selects a channel, the HCT identifies the 
service associated with the selected channel from the Display Channel 
Table and then executes the appropriate application determined from the 
Service Table of FIG. 3. 

20 Further, channel and service lineup can take place transparently to 

the viewer based on the data kept in the SAM client. This is important as 
subscribers often group together in blocks favorite types of programming 
so as to make access to those programs easier. In other words, a 
subscribers mapping of the settop terminal channels to television services 

26 



BNSDOCID: <WO 9957905A1_I_> 



WORLD INTELLECTUAL PROPERTY ORGANIZATION 
International Bureau 




PCT 

INTERNATIONAL APPLICATION PUBLISHED UNDER THE PATENT COOPERATION TREATY (PCT) 



(51) International Patent Classification 6 : 
H04N 7/173 



Al 



(11) Internationa! Publication Number: WO 99/57905 

(43) International Publication Date: 1 1 November 1 999 ( 1 1 . 1 1 .99) 



(21) International Application Number: PCT/US99/09278 

(22) International Filing Date: 29 April 1999 (29.04.99) 



(30) Priority Data: 

09/071 ,550 



1 May 1998 (01.05.98) 



US 



(71) Applicant: SCIENTIFIC-ATLANTA, INC. [US/US]; Intellec- 

tual Property Dept., Bamhardt, Hubert, J., HI, One Technol- 
ogy Parkway South, Norcross, GA 30092 (US). 

(72) Inventors: JERDING, Dean, F.; 315 Seventeenth Fwy., 

Roswell, GA 30076 (US). RODRIGUEZ, Arturo, A.; 5315 
Abigail Lane, Norcross, GA 30092 (US). SCHLARB, John, 
M.; 2040 North Creek Circle. Alpharetta, GA 30004 (US). 

(74) Agents: BARNHARDT, Hubert, J., Ill et al.; Scien- 
tific-Atlanta, Inc., Intellectual Property Dept., One 
Technology Parkway South, Norcross, GA 30092 (US). 



(81) Designated States: BR, JP, European patent (AT, BE, CH, CY, 
DE, DK, ES, FI, FR, GB, GR, IE, IT, LU, MC, NL, PT, 
SE). 



Published 

With international search report 



(54) Title: SYSTEM AND METHOD FOR PROVIDING A PLURALITY OF PROGRAMMING SERVICES IN A TELEVISION 
SYSTEM 

220 



rS 



CLOCK 



Cp— 



DATA 
PART 



RECEIVER 



PROCESSOR 
X X — 



TUNER 

t 



DISPLAY. 



225 



TERMINAL 



COMMANDS 
GUIDE INFO 
CHANNEL INFO 
CATEGORY INFO 



TRANSMITTER 



240 



(57) Abstract 



A system and method of providing for displaying a full service cable television system. The cable television system is adapted to 
provide a plurality of different user services. Accordingly, the system and method are designed to allow a user to access services in an 
efficient memory conserving fashion. Using a plurality of different services including cable channels, interactive program guides, pay per 
view activation, video on demand and interactive online services such as world wide web browsing and E-mail via their home television 
set. 



BNSDOCID: <WO 9957905A1_I_> 



FOR THE PURPOSES OF INFORMATION ONLY 
Codes used to identify States party to the PCT on the front pages of pamphlets publishing international applications under the PCT. 



AL 


Albania 


ES 


Spain 


LS 


Lesotho 


SI 


Slovenia 


AM 


Armenia 


Fl 


Finland 


LT 


Lithuania 


SK 


Slovakia 


AT 


Austria 


FR 


France 


LU 


Luxembourg 


SN 


Senegal 


AU 


Australia 


GA 


Gabon 


LV 


Latvia 


sz 


Swaziland 


AZ 


Azerbaijan 


GB 


United Kingdom 


MC 


Monaco 


TD 


Chad 


BA 


Bosnia and Herzegovina 


GE 


Georgia 


MD 


Republic of Moldova 


TG 


Togo 


BB 


Barbados 


GH 


Ghana 


MG 


Madagascar 


TJ 


Tajikistan 


BE 


Belgium 


GN 


Guinea 


MK 


The former Yugoslav 


TM 


Turkmenistan 


BF 


Burkina Faso 


GR 


Greece 




Republic of Macedonia 


TR 


Turkey 


BG 


Bulgaria 


HU 


Hungary 


ML 


Mali 


TT 


Trinidad and Tobago 


BJ 


Benin 


IE 


Ireland 


MN 


Mongolia 


tJA 


Ukraine 


BR 


Brazil 


IL 


Israel 


MR 


Mauritania 


UG 


Uganda 


BY 


Belarus 


IS 


Iceland 


MW 


Malawi 


US 


United States of America 


CA 


Canada 


IT 


Italy 


MX 


Mexico 


uz 


Uzbekistan 


CF 


Central African Republic 


JP 


Japan 


NE 


Niger 


VN 


Viet Nam 


CG 


Congo 


KE 


Kenya 


NL 


Netherlands 


YU 


Yugoslavia 


CH 


Switzerland 


KG 


Kyrgyzstan 


NO 


Norway 


ZW 


Zimbabwe 


ci 


Cote d'lvohe 


KP 


Democratic People's 


NZ 


New Zealand 






CM 


Cameroon 




Republic of Korea 


PL 


Poland 






CN 


China 


KR 


Republic of Korea 


PT 


Portugal 






CU 


Cuba 


KZ 


Kazakstan 


RO 


Romania 






CZ 


Czech Republic 


LC 


Saint Lucia 


RU 


Russian Federation 






DE 


Germany . 


LI 


Liechtenstein 


SD 


Sudan 






DK 


Denmark 


LK 


Sri Lanka 


SE 


Sweden 






EE 


Estonia 


LR 


Liberia 


SG 


Singapore 







BNSDOCID: <WO 9957906A1 J_> 



WO 99/57905 



PCT/US99/09278 



SYSTEM AND METHOD FOR PROVIDING A PLURALITY OF 
PROGRAMMING SERVICES IN A TELEVISION SYSTEM 

Technical Field 

This invention relates in general to television systems, and more 
particularly to a system and architecture for providing a plurality of 
different classes of video and multimedia programming and including the 
logical interface method for accessing said plurality of video and 
multimedia services. 

Background of the Invention 

The old definition of television services included a channel which 
was essentially nothing more than an analog broadcast video source. 
However, in the brave new world of digital programming, the home 
communication terminal ("HCT") otherwise known as the settop box has 
become a more powerful computing_device than the typical analog cable 
TV set-top. In addition to supporting traditional analog broadcast video 
and functionality, these devices must also support an increasing number 
of services which are not analog (but rather digital), are not broadcast 
(two-way communication as for example E-mail), and are not video (such 
as web browser). These are all in addition to a host of other television 
services which are increasingly being demanded by customers/examples 
of which include audio and audio visual programming, advanced 
navigation controls, interactive program guides, impulse pay-per-view 
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captivation, video on demand programming, advanced configuration 
controls, and other online services to name but a few. In order to provide 
these more powerful and complex features, the simple channel 
abstractions need to be extended beyond those which have traditionally 
5 been provided. 

With the capabilities of advanced one-way digital networks, a 
multiplicity of applications become feasible such as downstream e-mail 
delivery, electronic magazines, electronic newspapers, and other 
graphical and textual services for news, sports and financial information, 

10 to name but a few of broadcast authorizable services. With the 

capabilities of a two-way, digital network other applications such as 
impulse pay-per-view, video on demand, electronic commerce and web 
browsing become possible. All these services can be offered in parallel 
with conventional broadcast television and can be considered differing 

15 service categories. As the number of services available via cable or 
satellite television increases, there is a need for a model in which the 
television viewer can access these services. Given that a viewer of newer 
generation digital HCTs can access up to thousands of channels and 
services available, there will be a large amount of service and channel 

20 definition information that needs to be transmitted from the headend or 
server location to the client or HCT. Traditional methods of broadcast 
television and services in cable television systems do not provide the 
neceissary amounts of information to support all these channels and 
services, nor are they capable of efficiently transmitting, storing, 
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accessing, and processing the corresponding large amounts of information 
in the HCT. 

Cost limitations on HCT manufacture impose limitations in 
compute, memory, and internal machine bus bandwidth that in turn limit 
5 the amount of compute resources required to implement increasing digital 
video and multimedia functionality. Consequently, it would be desirable 
to provide a system in which required service related information is 
transmitted from the headend to the HCT in a methodical fashion so as to 
minimize: required network transmission bandwith; time to organize the 

10 information for storage in the HCT; memory footprint of the information 
in the HCT; and the amount of time required to then access the 
information in the HCT. Additionally, this information must be updated 
in an efficient manner such as that when the services and channel lineup 
are changed the HCT is provided the new information. 

15 It would also be desirable to provide this system and method in 

which a particular application for a specific service is preloaded on the 
HCT and, if not, arrange for it to be acquired from the headend and 
loaded. This, of course, would require the ability to have two-way digital 
cable TV network for communication between the headend and the HCT, 

20 or an advanced one-way digital network in which system and method 

acquires specific broadcast service information by accessing and retrieving 
data with a predetermined file name and identification, such file retrieved 
from a broadcast file system ("BFS"). 
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Accordingly, there exists a need to provide a mechanism whereby 
applications on the HCT can be activated from the server via a signaling 
message received from the HCT, to provide the user with services such as 
Emergency Alert Messages, email, and other messaging. 

5 

Brief Description of the Drawings 

FIG. 1 is a block diagram of a cable television system in accordance 
with the present invention; 

FIG. 2 is an electrical block diagram of a settop terminal included 
10 in the cable television system FIG. 1, in accordance with the present 
invention; 

FIG. 3 is a block diagram service application manager service table 
for a cable television system, in accordance with the instant invention; 

FIG. 4 is a block diagram representation of the display channel 
15 table used in connection with the service application manager of the 
instant invention; 

FIG. 5 is a block diagram representation of a split channel table 
used in connection with the service application manager, in accordance 
with the instant invention; 
20 FIG. 6 is a block diagram representation of a bulk table used in 

connection with the service application manager in accordance with the 
instant invention; and 
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FIG. 7 is a block diagram representative of a logo table used in 
connection with the service application manager, in accordance with the 
instant invention. 

5 Detailed Description of the Preferred Embodiments 

While the specification concludes with claims defining the features 
of the invention that are regarded as novel, it is believed that the 
invention would be better understood from a consideration of the following 
description in conjunction with the drawing figures in which like reference 

10 numerals are carried forward. 

Referring now to FIG. 1 there is illustrated therein a block diagram 
of a cable television system 100 including a headend 105 for receiving 
satellite television signals, demodulating the signals down to base band, 
and transmitting the signals over the system 100. The transmitted 

15 signals can, for instance, be radio frequency (RF) signals, although they 
may more preferably be optical signals that are transmitted over a 
communications medium such as a fiber optic cable 125. When optical 
signals are transmitted by the headend 105, one or more nodes 110 are 
included in the system 100 for converting the optical signals to RF signals 

20 that are thereafter routed over other media such as coaxial cables 130. 
Taps 115 are provided within the cable system 100 for splitting the RF 
signal off to subscriber equipment, such as settop terminals 120, cable 
ready televisions, video cassette recorders (VCRs) or computers. 
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Referring now to FIG. 2, there is illustrated therein a block diagram 
of the home communication terminal 120 and other system equipment is 
shown. The terminal 120 is typically situated within the residence or 
business of a subscriber. It may be integrated into a device that has a 
5 display 235, such as a television set, or it may be a stand alone unit that 
couples to an external display, such as a display included in the computer 
or a television, and that processes television signals for presentation to 
subscriber on the display. The terminal 120 preferably comprises a data 
port 205 for receiving the RF signals, which can include video, audio and 

10 data information, from the tap and providing any reverse information to 
the tap for transmission back to the headend. The terminal 120 further 
includes a processor 210 for controlling operations of the terminal 120 and 
for driving the display, a clock 215 for providing timing functions, and a 
tuner 134 for tuning into a particular audio, video, and/or data channel. 

15 Additionally, the terminal 120 includes a receiver 220 for receiving 
externally generated information, such as viewer inputs or commands 
from other devices. Viewer inputs could, for example, be provided via 
transmitter 240, such as buttons or keys located on the exterior of the 
terminal 120 or a handheld remote control device that includes user 

20 actuated buttons. Additionally, in certain embodiments, terminals 

include interface connectors for Ethernet port, Serial port, and Universal 
Serial Bus port. 

A memory 250, such as a nonvolatile volatile random access 
memory, coupled to the processor stores operational parameters such as 
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commands that are recognized by the processor. The memory also stores 
program and application information that can, for instance, be 
downloaded over the system to the terminal. The program information 
includes program guide information that is displayed for the subscriber in 
the format of a program guide including a listing of channels, programs for 
viewing on the channels, and times during which the programs are shown. 
The program information also includes channel information such as the 
channel number and identification information, e.g., ESPN, Disney, 
WXIA, etc. 

As noted above, in the world of digital programming, services are no 
longer considered to be simply traditional analog broadcast services, but 
will include advanced one-way digital network services and a whole host 
of additional two-way services such as web browsing, video on demand, 
and E-mail to name but a few. In order to provide these more powerful 
and complex features, the simple channel abstraction needs to be extended 
so as to provide for each of these different services in both one-way and 
two-way digital networks. The instant invention provides a Service 
Application Manager ("SAM") system and method that implements a 
model in which a viewer can access services. Each service identification 
consists, for example, of an application to run and a parameter, such as 
data content, specific to that service. Many services may be defined using 
the same application component, however with different parameters. For 
example, an application that can tune video programming would be 
executed with one set of parameters to view, for example, HBO, and a 
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separate set of parameters to view, for example, CNN. Each association of 
the application components (in this case tune video) and one of the 
parameter components (i.e., HBO or CNN) represents a particular service 
that has a unique service identification. Each of the other services 
5 described above, such as text channels, pay-per-view, video on demand 
and web browsing fit nicely within the service model. In addition to an 
application and parameter, each service also has an identity, which may 
include a short textual description (such as call letters for a particular 
television station), a long textual description, and a logo image. 

10 Additional service attributes in certain embodiments include 

multimedia service attributes. A service's identity is optionally 
augmented with an introductory audio that is played when the service is 
launched. A short "Welcome to ABC" song or voice with musical 
background, where such audio is distinctively associated with service is an 

15 example. Likewise, a service's identity is optionally augmented with an 
audio for when service is terminated or suspended. 

In other embodiments, a special effect when starting a service, 
including animated transition into the service such as morphing from an 
image of service logo to displayable service, or graphics transitions such as 

20 implosion and fades, may be associated with the service. Likewise, a 
special effect may be associated with a service when it is terminated or 
suspended. 

In another embodiment, any of a partial or full-size image, video or 
video widget serving the function of a 3-D logo is associated with a service 
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and displayed momentarily when service is launched. Same or different 
counterpart media is employed for service termination or suspension. The 
specified association of media with service may include an amount of time 
to display or play the media. Additionally, media can be combined with 
5 special effects. 

Service attributes may or may not necessarily be for identification 
services but for efficiency of system and method. Such service attributes 
include: cable-operator-only launchable service messaging viewer with 
emergency alerts or reminders to pay bill. A service can be classified with 
10 an attribute as both, a cable-operator and viewer, launchable service. 
Alternately, a service attribute is an installer-only or repair- 
representative-only launchable service. 

A service can be classified with an attribute as one that can be 
launched by time, rather than immediately to responding to viewer input 
15 or headend signaling. Furthermore, such service activation time is 
designated by: 

A. a prespecified time after viewer activation or server signaling; or 

B. input by viewer or data transmitted during server signaling, 
and/or possibly with: 

20 1. periodic pre-specified interval values; or 

2. periodic pre-specified interval values specified by 
viewer or headend message. 
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Examples of a service that is launched periodically is a ticker-tape that 
displays periodic information updates of sports scores or stock prices. 
Specification of service display duration is included appropriately in the 
aforementioned. A service can also be classified with an attribute as a 
5 "service not-blockable by viewer" that is activated by cable headend 
operator. 

A service may have the attribute of a background-service, not 
visible to viewer. In a HCT, a service that enables HCT to route Internet 
Protocol data or other information received from and to digital network 

10 and passed via one of many possible HCT communication ports to and 
from one or more of many computing devices in the viewer's premises, 
establishes a communication link between the digital network and . 
computing devices. Such computing devices include an advanced phone, a 
hand-held electronic organizer device, a personal computer, an appliance 

15 such as a stove, and therefore the HCT acts as a cable modem. 

Although a service runs in the HCT in the forementioned, the 
application running on the HCT serves as an "enabler" and possibly as a 
communication switch while the designated computing device and 
communication port are specified as parameters of the service. HCT 

20 communication ports include Ethernet port, serial port, Universal Serial 
Bus (USB), to name a few. 

In order to access this growing number of services, it is necessary to 
provide a system which can meet functionality, efficiency, and memory 
footprint requirements constrained by the capabilities of the HCT. The 

10 
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Service Application Manager ("SAM") architecture consists of a SAM 
server component, a SAM client component, and the interface between-the 
server to the client. This interface consists of the SAM information tables 
broadcast on the BFS (an example of which is disclosed in commonly 
5 assigned patent application serial no. PCT/US97/22535, the disclosure of 
which is incorporated herein by reference) and the update and signaling 
messages passed from server to client. In the context of the system 
illustrated in Figs. 1 and 2, the SAM server component is part of the 
headend, while the SAM client component resides in the HCT. The SAM 

10 server stores the current SAM information which consists of a Service 
Table, a Display Channel Table, a Split Channel Table, the Bulk Table, 
and the Logo Table. The SAM provides an interface for a server operator 
to enter and modify the information on the SAM, and to broadcast it to 
SAM clients notifying them of, for example, information changes. The 

15 SAM also allows the applications which execute a particular service to be 
introduced into the system. Each application has a server component and 
a client component. The application server may execute all the time, 
while an application client may be downloaded to the HCT and executed 
only when the viewer requests the service be activated. 

20 The SAM server provides an interface through which applications 

are placed on the network, services registered, a channel lineup specified, 
and the SAM information stored and modified. The SAM server may also 
allow changes to the SAM information table (as described herein below) to 
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be posted to the network together with a time specified by the cable 
operator. 

The SAM client provides an interface through which applications 
may be activated and SAM information can be accessed. One functionality 
5 of the SAM client is the activation of an application client on the HCT, 
either to provide a specified service or because of a signaling message from 
the server. 

As noted above SAM information includes at least five different 
tables: a Service Table stores information about all services available on 

10 the system and each service is identified by a specific service ID; a Display 
Channel Table ("DCT") provides an abstraction to match a display channel 
number to a service ID (and vice versa); a Split Channel Table 
supplements the DCT with information about split channels; a Bulk Table 
is provided for storing actual string and parameter data as well as 

15 attributes of each service. The data for each table may be transmitted 
from the server to the client by writing it into a binary file and then 
placing the file on a broadcast file system ("BFS") such as that disclosed in 
the aforementioned copending PCT Patent Application, the disclosure of 
which is incorporated herein by reference. Updates to the various table 

20 increments the tables' version number. Accordingly, the system will 
always access the most recent version of a particular table. This is 
important as some channels, for example the Split Channel Table, will 
change fairly regularly and indeed can change on a daily basis. 

12 
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When the SAM server changes the SAM files being broadcast on 
BFS, the SAM client will receive a message from the SAM server via the 
HCT operating system. This message contains the current version 
number of each SAM table, as well as flags optionally specifying a "forced" 
5 update of each table. For each table, the SAM client will check the version 
number specified in the message versus the local table versions and only if 
they are different retrieve the file from the BFS and check the version 
number a second time (unless the "force" flag is set for that table, in which 
case the file on BFS is always checked). If a file version being transmitted 
10 on the BFS is different than the local file stored in the SAM client, the 
SAM client will update its tables using the new files. 

The update process works such that while the SAM client is reading 
new files, the old files are still available to applications on the HCT. Only 
when the SAM client has completed reading any new tables does it 
15 actually update the current tables to the new information. During this 
very brief "swap", both old and new tables are locked such that the data 
cannot be accessed via the SAM client interface. 

The update process is also robust such that the SAM client can 
handle the various non-deterministic aspects of the SAM server's use of 
20 the BFS. For example, the synchronization of the message being received 
at the client, the file being changed on the BFS server, and the file being 
changed as seen by the BFS client are all affected by network latency and 
could happen in different orders. 

13 
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After receiving an information update, the SAM client will notify 
interested applications via the HCT OS that the SAM information has 
changed. To allow other components to update their service and channel 
related information, the SAM client must keep the last version of the 
5 replaced data tables in memory. 

The various SAM information tables are transmitted in band, over 
QAM, for fast access by the SAM client during HCT boot. Copies of the 
tables, with the exception of the Logo Table, are also transmitted out-of- 
band, over QPSK. The out of band files are used by the SAM client during 

10 SAM information update such that the viewer's use of the HCT is not 
interrupted (access to in-band data requires use of the HCT tuner). 

Referring now to FIG. 3 there is a block diagram representation of 
the Service Table used in the preferred embodiment of the Service 
Application Manager, all in accordance with the instant invention. The 

15 Service Table 300 contains the service identification information, with 
each service assigned a unique service ID. The header information at the 
beginning of the Service Table includes the table version 308 and the 
number of sub tables 310. This is followed by the service subtables. Each 
subtable 302 includes the number of subtable entries, the length of the 

20 service data segment, an index, and finally the service data segment. The 
index includes a pairing of a service ID and the offset into the data 
segment where the service data is actually found. Accordingly, if a 
particular subtable provides information relating to 25 different services, 
the index will include 25 blocks, each block corresponding to a single 

14 
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service. The service IDs 306 across the entire Service Table are stored in 
increasing order, but are not necessarily contiguous. Each service 
subtable can store up to 64Kb of service data. 

To find a service ID in the Service Table, a binary search is done 
first on the subtables to determine which subtable a service ID is in, and 
then within the index of the subtable to locate the offset of the service data 
in that subtable. The offset is then used to access the data directly. 

Each service data record includes all of the service attributes. One 
such attribute is a description ID. The description ID is an index into the 
Bulk Table for the string describing the service. In one embodiment, each 
string is made up of three fields: (1) an ascii string decimal number 
specifying the length of the short description in characters; (2) a short 
description ascii string; and (3) a long description ascii string. For 
example, the following strings describe a service whose short description is 
"WTHR", and the long description is "The Weather Channel": "4WTHR 
The Weather Channel/' 

A second piece of data which is located in the data block 320 is a 
logo ID and which itself is an index into the Logo Table for the service's 
logo pixel map. An application Universal Resource Locator ("URL") ID is 
a third index into the Bulk Table for the URL string identifying the 
application client in the broadcast file system. The final attribute is an 
application dependent parameter, which is interpreted as a number (i.e., 
a source ID) or an index into the Bulk Table for a parameter string or 
parameter data. 

15 
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In order to efficiently store service records for thousands of services, 
the invention specifies a record with variable-length fields. The idea is to 
use only as much memory for a field as is needed for the particular value 
of that field. The field Size attribute of the service is used to specify the 
5 size, in bytes, of each field. The field Size byte uses 2 bits to encoding the 
number of bytes minus 1 for each field. A value of "00" in a field means it 
is 1 byte, "01" means 2 bytes, etc. No matter what the actual field size, 
the access operations always return the field value in 32 bits. The access 
routines must operate at a byte level when retrieving fields larger than a 
10 byte because the data will not be word or half-word aligned. The format of 
the field Size byte is shown below: 

field Size: for(i = bit 0; i < 8; i++) { 

description ID size -1:2 
logold size -1:2 
15 applicationld size -1:2 

parameter size -1:2 

Thus, each record varies in length from 5 to 17 bytes. 

Accordingly, and referring now to FIG. 4, there is illustrated therein 
20 in a block diagram representation of the Bulk Table used in connection 
with the Service Application Manager, all in accordance with the instant 
invention. The Bulk Table 400 contains data relevant to the services, 
such as strings for descriptions, application URLs, and parameter data. 
As with the Service Table 300 of FIG. 3, the Bulk Table comprises several 

BNSDOCID: <WO 9957905A1_I_> 



WO 99/57905 PCT/US99/09278 
initial entries 402, 404 as described above, followed by a plurality of bulk 
information subtables 406 and 408. 

Each subtable includes the number of subtable entries, the length of 
the bulk data segment, an index, and finally the bulk data segment. The 
index includes a pairing of a bulk ID and the offset into the data segment 
where the bulk data is actually found. Accordingly, if a particular 
subtable provides information relating to 25 different bulk data entries, 
the index will include 25 blocks, each block corresponding to a single bulk 
data item. The bulk IDs across the entire Service Table are stored in 
increasing order, but are not necessarily contiguous. Each bulk subtable 
can store up to 64Kb of bulk data. 

To find a bulk ID in the Bulk Table, a binary search is done first on 
the subtables to determine which subtable a bulk ID is in, and then within 
the index of the subtable to locate the offset of the bulk data in that 
subtable. The offset is then used to access the data directly. 

The size and the contents of the Bulk Table itself depends on the 
size and type of information which is required to be stored therein. 
Several types of BulkData are defined in the following. The application 
URL is simply a NULL-terminated ASCII string. The service description 
is two concatenated NULL-terminated ASCII strings, the first being the 
short description and the second being the long description. For example, 
"WGNX\0CBS Atlanta\0" is a possible description string. A string is 
simply a NULL-terminated ASCII string. Arbitrary data can be stored in 
the Bulk Table and a pointer to that data handed out via an API in the 

17 
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SAM Client. It is then up to the application client to interpret the content 
of the data. 

Referring now to FIG. 5, there is illustrated therein a block diagram 
representation of the Display Channel Table used in connection with the 
5 Service Application Manager, all in accordance with the instant invention. 
The Display Channel Table 500 is used to map service IDs to channel 
numbers displayed to the viewer (Display Channel Number, or DCN). In 
one embodiment of a cable system using the SAM, the Display Channel 
Table can be specified on a per-hub basis. This allows different 
10 neighborhoods of subscribers to receive different channel lineups. 

The Display Channel Table is constructed to allow optimal access 
time to determine the service ID for a particular service or the service ID 
for a particular DCN. Both transformations are required by applications 
executing in the HCT such as the channel navigator and the program 
15 guide. 

The Display Channel Table begins with a version number 502, the 
number of valid channels in the channel index 504, and the length of the 
valid service index 506. This is followed first by a valid channel bitmap 
508, containing a bit for each channel in the cable system. For each 
20 channel that is valid, the corresponding bit position is set in the valid 

channel bitmap. Next is a valid channel index 510, each entry associated 
with a valid channel in the bitmap, whose content is an index into the 
service/DCN index that follows. The service/DCN index contains an entry 
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for each valid service ID and Display Channel Number pair. Within each 
Display Channel Number in that pair 

is a channel flag (the most-significant-bit of the DCN). This flag indicates 
whether or not the DCN is surfable, i.e. can be reached by the user 
incrementing or decrementing throughout the channel lineup. There 
exists a service ID/DCN pair for every combination of service and DCN, 
where a service can be associated with more than one channel. 

These data structures can be better understood by explaining how 
the translation for service ID to DCN and vice-versa takes place. To 
translate from DCN to service ID, first the bit for the DCN in the valid 
channel bitmap is checked. If the bit is set, the channel is valid, and the 
index for that channel must be determined. The index is exactly Nth valid 
channel which the DCN happens to be, or the number of bits set in the 
valid channel bitmap up to and including the bit representing the DCN. 
This lookup is made compute efficient by using a table which stores the 
number of bits set in a single byte for each decimal value of that byte. 
Thus, the channel index can be determined by taking the decimal value of 
each byte in the valid channel bitmap, translating the decimal value to a 
"number of bits set" using the lookup table, and accumulating this count 
for each byte in the valid channel bitmap up to the byte for the DCN. The 
remaining bits in the byte where the DCN bit is located are added by 
shifting and masking. 

The number of bits set is then directly the Nth valid channel for 
that DCN, which is directly the offset into the channel index for that DCN. 

19 
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The channel index contains the offset into the service/DCN index for that 
DCN. Once this offset is known, the service ID for that DCN is the upper 
two bytes of the 32-bit service ID/DCN value. The total search time is 
then O(n) where n is the number of total possible channels. This is 
5 achieved without having to store for example an array of size total number 
of channels, using only an array of size total number of channels divided 
by eight (the bitmap) plus an array of size number of valid channels. 

To look up a service ID for a DCN, a binary search on the service 
ID/DCN index 512 is done. This index is sorted in increasing order, such 

10 that the search is 0(log (number of valid service/DCN entries)). 

In addition to the services described above, the SAM supports the 
ability to split channels provided over the system. A split channel is one 
in which there is more than one service which is provided on that channel 
during a 24 hour period. One embodiment of the SAM may support split 

15 channelsj where each of which shows two services, and which may change 
between those two services up to three times in a 24 hour period. For 
example if the channel is specified as a split channel with service X and 
service Y, starting at midnight the following splits are available: XY, 
XYX, XYXY. Split channels are identified in the Display Channel Table in 

20 both the channel index and the service ID/DCN index using a reserved 
constant. This indicates to the SAM client to lookup the information for 
the requested DCN in the Split Channel Table. There is always a Split 
Channel Table for each Display Channel Table in which a split channel is 
identified. 

20 
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Accordingly, referring now to FIG. 6, there is illustrated therein a 
block diagram representation a Split Channel Table 600 for use in 
connection with the Service Application Manager, all in accordance with 
the instant invention. The Split Channel Table, like the other tables, 
5 includes a number of initial entries such as initial entry 602 and 604. 
Initial entry 602 is version which specifies the most recent version of the 
split channel table allowing the SAM system to know that it is working 
with the most recent version of information. The second entry 604 
specifies the number of split channels in the channel lineup. Accordingly, 

10 and in FIG. 6, the number of split channels identified would be one as only 
one split channel record 606 is illustrated in split channel table 600. It is 
to be understood, however, that any number of split channels may be 
supported by this system, and the invention is not so limited. The split 
channel record 606 includes a number of pieces of information, including, 

15 for example, the DCN being split 608, the identities of the services which 
are splitting the channel 610 and 612, and a time flag 614 which specifies 
the hours at which services are being provided on the channel. These 
times are specified such that service 1 is on by default at midnight in any 
given day. Each time then marks a swap to service 2 and back, continuing 

20 according to the number of swaps. The core channel management 

application in the HCT uses this information such that service swaps take 
place automatically and are done by the client. This differs from existing 
analog systems where split channels are implemented by changing the 
content which is broadcast on a particular analog channel. The split 

21 
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channel concept in this invention also allows channels to be split between 
video services and services of other media, such as text channels or web 
browsing time. 

The final SAM information table present in the instant invention is 
5 the Logo Table as illustrated in FIG. 7. The Logo Table 700 stores service 
logo data. The SAM server provides two different Logo Tables on the BFS, 
both transmitted in band. One table provides the default set of logos 
known by the SAM Server upon deployment of the cable system, in the 
present embodiment the range of default logo IDs is from 1-255 and is 
10 published including the name of the logo. The data for the default logo 

images can be stored in the nonvolatile memory of the HCT such that they 
can be retrieved very quickly and rendered by applications in the HCT. 
The set of default logos will never change, nor will the data in the default 
Logo Table. 

15 New logos registered with services by the SAM server are stored in 

another Logo Table. The SAM client always loads this table into memory 
on the HCT during initialization, and it can be updated like any of the 
other SAM information tables. Accordingly, the Logo Table initial entry 
702 relates to version numbers of the table. 

20 All logos are encoded by the SAM Server using an encoder that 

translates a single common image format such as GIF into the particular 
format that the SAM is transmitting (and decoding within the SAM 
Client). 
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Application clients can access the logo data in the SAM in several 
ways. First, an application client can ask for the logo ID that corresponds 
to a particular service. If the logo ID is stored by the application client 
(one of the default logos), it can then draw the appropriate logo using its 
5 own data. Otherwise, the application client can ask the SAM client for the 
logo pixmap data, width, and height in a format compatible with the HCT 
OS drawing capabilities. A Logold of zero means no logo. 

The structure of the Logo Table begins with a version number 702, 
number of logos 704 in the table, first logo ID in the table 706, and then 

10 the size of the logo data 708. Next is an index of logo data offsets 710, 

such that index equals the logo ID minus the starting logo ID of the table. 
The index for a logo contains the offset into the logo data segment where 
the actual image data for the logo is stored. 

The primary functionality of the SAM is the activation of an 

15 application client on the DHCT, either to provide a specified service or 
because of a signaling message from the server. Typically the user of the 
DHCT will access services via the Display Channel Number (DCN). The 
SAM uses the Display Channel Table (DCT) to map a DCN to a Serviceld. 
"Split" channels are supported, such that one channel might provide 

20 multiple services, depending on the time of day. Given a service ID, the 
SAM Client first extracts the appropriate application URL BulkDatald 
from the Service record in the current Service Table, and then the actual 
URL string from the Bulk Table. It then asks the HCT Operating System 
("OS") if the module with the application URL for the application is loaded 
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in the HCT memory. If not, it requests that the OS load the module using 
the application URL. Once the application code is resident in the HCT, 
the SAM client launches the application module as an OS application (it 
may be that the application has already been launched). It then asks the 
5 OS to activate the application, given the module handle-this brings the 
application into focus. Finally, the SAM client sends a kEt_Activate 
message to the application client, including the service ID and the service 
parameter from the Service Table. 

Application clients can also be activated by a message sent from the 

10 server. The SAM client must register with the HCT operating system to 
receive SAM signaling messages. The content of these messages is an 
application URL to activate and the data to pass the application as a 
parameter. The SAM client thus provides a mechanism whereby an 
application client can be activated given the application URL and some 

15 data. If the data type is an integer value, meaning the parameter itself, 
then it is passed directly to the application identified by the URL via a 
kEt_Activate message. However, if the parameter is a string or data, then 
it must be stored by the SAM client locally and given a BulkDatald in the 
range reserved for private client use. The SAM client will activate the 

20 application client. The BulkDatald is passed as the parameter, and a 
special id is used to signify a service activated via a pass-thru message. 
The application client can then use the SAM client API to retrieve the 
data given the bulk ID. Depending on the application, the private bulk 
data might be a URL string, an actual string to use directly, or data. The 
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application client must be given the parameter type it is expecting; this 
must be verified by the SAM Server before the signaling message is sent. 
However, if the application client is expecting a string it must check 
whether the string is a URL or the content itself. If the application client 
is executing on behalf of the kSam_SignalingService, then it must delete 
the private bulk data when it suspends 

The SAM client can be asked to construct a kEt_Notify event with 
supplied parameters and forward it to designated application clients. 
Again, this can be done via a service ID or an application URL. The 
notification event type is supplemented with event data particular to the 
notification being sent (such as kEd_SamDataUpdated), an ID (typically 
the service ID), and two parameters. 

The SAM client provides a facility whereby application clients can 
be queried to determine whether particular services are currently 
authorized. The SAM will look up the application URL for the requested 
service ID in the Service Table, and send the application client a 
kEt JsAuthorized event requesting an asynchronous reply to a queue 
created within the SAM client API. The SAM client will wait on that 
queue until a kEt_AsyncResponse event is delivered by the application 
client, and then return the result to the caller of the SAM API. Thus, 
while the internals of the authorization query are asynchronous, the SAM 
Client API is synchronous. It is up to the application client to determine if 
the service is authorized, using whatever means necessary. 
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Application clients can be suspended by Serviceld or directly via 
application URL. Application clients can also be suspended as a result of 
a signaling message from the SAM Server. 

Accordingly, in the system illustrated in Figs. 1 and 2 it may be 
5 appreciated that the channel selection function of this system includes a 
plurality of channel cross reference tables as illustrated in Figs. 3-7. 
These tables cross reference settop terminal channels with a variety of 
television services, or other services, such as various types of video and 
audio programming, and online services such as web casting and E-mail. 

10 Selection of a particular channel transfers control of that specific 

application program, along with one or more appropriate parameters 
obtained from the cross reference tables, and activates the service 
associated with that selected channel. In sum, the cross reference tables 
in Figs. 3-7 are channel selection functions which enable the settop 

15 terminals to execute software and activate a variety of services. When a 
viewer of the system of FIG. 1 selects a channel, the HCT identifies the 
service associated with the selected channel from the Display Channel 
Table and then executes the appropriate application determined from the 
Service Table of FIG. 3. 

20 Further, channel and service lineup can take place transparently to 

the viewer based on the data kept in the SAM client. This is important as 
subscribers often group together in blocks favorite types of programming 
so as to make access to those programs easier. In other words, a . 
subscribers mapping of the settop terminal channels to television services 
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is maintained even if the cable service provider reassigns the cable 
channels over which those services are transmitted. Accordingly, when 
such reassignment occurs, updated versions of the few tables as specified 
hereinabove are transmitted from the SAM server to the SAM client, thus 
5 providing a transparent change in service channels for the SAM server 
operator through to the SAM client user. As an example, once parents 
configure channel settings to block particular services deemed 
inappropriate for children, a reassignment of cable channels over which 
those services are transmitted will not affect those services blocked status. 

10 The manner in which requests for services are made by different 

applications within HCT are simplified by incorporating an application 
URL, similar to that used on the Internet, to uniformly identify 
application requested. In the context of services described hereinabove, it 
has been set forth that the service comprises a application and a 

15 parameter. The application in fact the URL to the executable application 
code, found either on the BFS or resident in HCT memory, while the 
parameter includes the data strings described herein above. 

While the preferred embodiments of the inviention have been 
20 illustrated and described, it will be clear that the invention is not so 

limited. Numerous modifications, changes, variations, substitutions and 
equivalents will occur to those skilled in the art without departing from 
the spirit and scope of the present invention as defined by the appended 
claims. 
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Claims 

1. An apparatus for activating television services in a television 
broadcast system, said system comprising a system server device and a 
5 system client device, said apparatus comprising a subscriber input device 
for selecting a client television service, each said service including an 
application and a parameter; and 

a central processing unit in communication with said client and 
server devices wherein said central processing unit selectively accesses a 
10 first table in response to the user selected television service; said first 
table selectively accessing at least a second and third table in order to 
identify the application and parameter associated with said service. 
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